Field of the Invention
The present disclosure relates to data processing. In particular, but not exclusively, the present disclosure relates to processing data in a telecommunications network.
Description of the Related Technology
In a standard IP Multimedia Subsystem (IMS) network, when a Serving Call Session Control Function S-CSCF is processing a Session Initiation Protocol (SIP) request it looks up the Initial Filter Criteria (IFC) for the originating and/or terminating subscriber(s) from the Home Subscriber Service (HSS) and uses this to decide which application servers to invoke while processing the call. Typically, this means a set of application servers are invoked one after another by sending the SIP request (which could be an INVITE or other dialog initiating request) to each application server in turn. Each application server can either respond to the request itself (in which case, no later application servers in the list are invoked), or it can allow the request to continue by sending it back to the S-CSCF, possibly after modifying the message (in which case, the S-CSCF will route the request to the next application server in the list). This routing is achieved by adding two route headers to the message. The first route header has the uniform resource identifier (URI) of the application server. The second route header has a URI with the S-CSCF node's host name and an Original Dialog Identifier (ODI) token. The second Route header both allows the request to get back to the correct S-CSCF and allows the S-CSCF to find the state corresponding to the IFC so it can resume processing from the right point in the list.
The above process is complicated by the fact that the IFC have to be re-evaluated hop-by-hop in case an earlier application server changes the messages in a way that affects whether subsequent triggers in the IFC would fire. This means an implementation that simply calculates the list of application servers upfront then routes the message via them all will not work.
In a system which does not employ a longstanding assignment of a given subscriber to a given network routing node, i.e. any network routing node among a plurality of network routing nodes is enabled to process messages relating to any given subscriber, one way to implement the above process is to have each network routing node act as if it were a S-CSCF in the above processing, so that each request is processed by the same network routing node, and that network routing node maintains local state information that it correlates to the ODI tokens when requests come back from the application servers. With such a system, one decision which has to be made is how long to retain the state information associated with a request. One candidate lifetime is the lifetime of the SIP transaction associated with the request, so the state information would be discarded when a final response is sent to the initial SIP request. However, the IMS specifications are not definitive on this lifetime, and there are some possible application server flows that would not work with this lifetime.
For example, if an application server sends a final response to the initial request, then later sends the request back to the network routing node, the network routing node would not correlate the ODI token and would process the request as a new request, resulting in the request being sent back to the same application server. An example where this may occur is a calling card application, where the application server sends a final response to the initial request in order to establish a media connection on which to play a prompt and collect the calling card number, and sends the request back to the network routing node when the appropriate card number has been entered.
There is therefore an alternative school of thought that the state information associated with the SIP request should be longer than the SIP transaction in order to handle this case. Here, options would seem to include maintaining the information for a fixed time after the SIP transaction has ended, or to maintain the information for the entire duration of the SIP dialog. Given the likely use cases that hit this problem involve user input, a timer based solution is unlikely to work in all cases.
A traditional S-CSCF would have no problem maintaining the state information for the duration of the SIP dialog because it remains in the SIP signalling path for the whole dialog and so can maintain sufficient dialog state information. However, in a system which does not employ a longstanding assignment of a given subscriber to a given network routing node, network routing nodes may not stay in the SIP signalling path after the initial transaction and would not be able to maintain dialog state information.
It would therefore be desirable to provide improved measures for processing data in a telecommunications network, including maintaining state information associated with processing IFC.